Capítulo 9 - Evolución del Software
Los sistemas de software operativos necesitan evolucionar para seguir siendo útiles. Los cambios empresariales, las expectativas de los usuarios, los cambios en las plataformas de hardware y software, y la competencia impulsan la necesidad de modificaciones, correcciones de errores y mejoras de rendimiento.
Los grandes sistemas de software, como los militares o los de infraestructuras, suelen tener una vida útil de 30 años o más. Los sistemas empresariales pueden tener más de 10 años. La longevidad se debe a la necesidad de recuperar la inversión realizada en el desarrollo del software.
Las empresas invierten en cambios de software para mantener el valor de sus activos empresariales críticos. El coste de mantenimiento de los sistemas existentes suele ser mayor que el de desarrollo de los nuevos. Los estudios indican que entre el 60% y el 90% de los costes de software están asociados a la evolución.
La evolución del software es más compleja en los sistemas empresariales que forman parte de un "sistema de sistemas" más amplio. Los cambios en un sistema pueden afectar a otros sistemas dentro del entorno operativo, lo que requiere un análisis cuidadoso del impacto más amplio.
La ingeniería de software sigue un proceso en espiral durante toda la vida útil del sistema. Se crean versiones periódicas para incorporar cambios y actualizaciones basados en la evolución de los requisitos. El desarrollo de versiones posteriores puede comenzar incluso antes de que se publique la versión actual.
En general, los sistemas de software tienen una larga vida útil y requieren una evolución y adaptación continuas para satisfacer las necesidades cambiantes de la empresa y los factores del entorno. La ingeniería del software sigue un proceso en espiral continuo para apoyar estos sistemas en evolución.
En la última década, el tiempo entre iteraciones de la espiral de desarrollo de software ha disminuido significativamente. Con la llegada de Internet y las presiones de la competencia, algunas aplicaciones y sistemas basados en la web lanzan ahora nuevas versiones en cuestión de semanas, impulsadas por la necesidad de responder rápidamente a los comentarios de los usuarios.
Rajlich y Bennett proponen una visión alternativa del ciclo de vida de la evolución del software para sistemas empresariales.
Estas fases se solapan entre sí.
Durante la fase de evolución, las partes interesadas proponen y aplican numerosos cambios para satisfacer los requisitos cambiantes. Sin embargo, a medida que el software sufre modificaciones, su estructura tiende a degradarse, lo que conlleva mayores costes para los cambios del sistema. Esta degradación suele observarse al cabo de unos años de uso, coincidiendo con la necesidad de actualizar el hardware y el sistema operativo.
A medida que el software madura, alcanza un punto de transición en el que implementar cambios significativos y nuevos requisitos resulta menos rentable, lo que marca el paso de la evolución al mantenimiento.
En la fase de mantenimiento, el software sigue siendo funcional pero sólo recibe cambios tácticos menores. Las organizaciones suelen empezar a considerar la sustitución del software durante esta fase. En la fase final, se realizan cambios esenciales en el software y los usuarios deben solucionar los problemas detectados. Finalmente, el software se retira y deja de utilizarse, lo que puede acarrear gastos adicionales para transferir los datos a un sistema de sustitución más reciente.
Cuando la misma empresa es responsable del software durante toda su vida útil, se produce una transición fluida del desarrollo a la evolución. Se aplican sistemáticamente los mismos métodos y procesos de desarrollo de software. Este modelo se utiliza habitualmente para productos de software y aplicaciones.
La evolución del software a medida suele seguir un modelo diferente. El cliente del sistema puede contratar inicialmente a una empresa de software para el desarrollo, pero más tarde se hace cargo del soporte y la evolución utilizando su propio personal. Otra posibilidad es firmar un contrato independiente con otra empresa de software para el soporte y la evolución del sistema.
En situaciones en las que diferentes empresas participan en las fases de desarrollo y evolución, puede haber discontinuidades en el proceso de evolución. Es posible que los requisitos y los documentos de diseño no se transfieran sin problemas de una empresa a otra. Las fusiones, reorganizaciones y la herencia de software de otras empresas pueden complicar aún más el proceso.
Cuando la transición del desarrollo a la evolución no es fluida, el proceso de cambiar el software después de la entrega se denomina mantenimiento del software. El mantenimiento implica actividades adicionales, como la comprensión del programa, junto con las actividades habituales de desarrollo de software.
Los procesos de evolución del software varían dependiendo del tipo de software que se mantiene, de los procesos de desarrollo usados en la organización y de las habilidades de las personas que intervienen.
Las propuestas de cambio al sistema son el motor para la evolución del sistema en todas las organizaciones. Estos cambios provienen de:
La identificación de los cambios y la evolución continúan a lo largo del tiempo de vida del sistema.
Se deben identificar y relacionar los componentes que son afectados por un cambio, permitiendo así estimar el costo y el impacto del cambio.
La siguiente figura muestra un panorama del proceso de evolución, el cual incluye actividades fundamentales de análisis del cambio, planeación de la versión, implementación del sistema y su liberación a los clientes.
El costo y el impacto de dichos cambios se valoran para saber qué tanto resultará afectado el sistema por el cambio y cuánto costaría.
Se planifica una nueva versión con los cambios aceptados.
Si los cambios propuestos se aceptan, se planea una nueva versión del sistema. Durante la planeación de la versión se consideran todos los cambios propuestos (reparación de fallas, adaptación y nueva funcionalidad). Entonces se toma una decisión acerca de cuáles cambios implementar en la siguiente versión del sistema.
Después de implementarse, se valida y se libera una nueva versión del sistema.
Luego, el proceso se repite con un conjunto nuevo de cambios propuestos para la siguiente liberación.
Es posible considerar la implementación del cambio como una iteración del proceso de desarrollo, donde las revisiones al sistema se diseñan, se aplican y se ponen a prueba.
Durante el proceso, se analizan los requerimientos y pueden surgir modificaciones a los cambios propuestos.
Cuando el equipo de mantenimiento es diferente al de desarrollo, la implementación incluye una comprensión del programa.
De manera ideal, la etapa de implementación del cambio de este proceso debe modificar la especificación, el diseño y la implementación del sistema para reflejar los cambios al mismo:
En ocasiones, las peticiones de cambio se relacionan con problemas del sistema que tienen que enfrentarse de manera urgente. Surgen básicamente por tres razones:
En vez de modificar los requerimientos y el diseño, se puede hacer una reparación de emergencia al programa para resolver el problema de inmediato:
Sin embargo, el riesgo es que los requerimientos, el diseño del software y el código se vuelvan inconsistentes. Se elige una solución rápida y viable, en lugar de la mejor solución en cuanto a la estructura del sistema.
Luego de una reparación de emergencia, se debería refactorizar el código para mejorarlo.
Los métodos y procesos ágiles se utilizan tanto para la evolución del programa como para su desarrollo. Hacer la transición del desarrollo ágil a la evolución posterior a la entrega no debería tener complicaciones.
Las pruebas de regresión automatizadas son muy valiosas cuando se realizan cambios en el sistema.
Los cambios pueden ser expresados como historias de usuario adicionales.
Sin embargo, es posible que surjan problemas en situaciones donde haya transferencia:
En una organización, los sistemas se remplazan a medida que el negocio cambia.
Sin embargo, muchos viejos sistemas continúan siendo utilizados, e incluso, tienen un rol crítico en el negocio. Estos son llamados sistemas heredados.
No son solo sistemas de software. Abarcan hardware, software, librerías, software de soporte y procesos de negocio.
Han tenido mantenimiento por un largo tiempo, por lo que su estructura puede estar degradada.
Pueden depender de hardware antiguo.
Es probable que no soporten nuevos procesos de negocio.
El mantenimiento de estos sistemas tiene dificultades y es costoso.
Tomar la decisión de remplazar un sistema heredado puede ser costoso y riesgoso.
Las organizaciones que se basan en sistemas heredados deben elegir la estrategia para la evolución de ellos.
La estrategia elegida dependerá de la calidad del sistema y del valor del sistema para el negocio.
La evaluación debe tomar en cuenta diferentes puntos de vista:
Entrevistar diferentes interesados y cotejar resultados.
Es la modificación de un programa luego de que está siendo utilizado.
EI término se utiliza, sobre todo, para realizar cambios en el software personalizado.
Normalmente el mantenimiento no genera grandes cambios en la arquitectura del sistema.
Los cambios implican modificar componentes existentes y agregar nuevos componentes al sistema.
Correctivo (21%)
Control del funcionamiento diario del sistema a través de la reparación de fallas
Adaptativo (25%)
EI sistema de modifica para adaptarse a cambios en el entorno
Perfectivo (50%)
Mejorar funcionalidades existentes
Preventivo (4%)
Prevenir que el desempeño del software se degrade
La predicción del mantenimiento se ocupa de evaluar qué partes del sistema pueden causar problemas y cuál serán los costos de mantenimiento.
Es la predicción de la cantidad de cambios requeridos y la comprensión de las relaciones entre el sistema y su entorno.
Los sistemas fuertemente acoplados requieren cambios cada vez que cambia su entorno.
Los factores que influencian esta relación son:
Las predicciones de mantenimiento se pueden realizar mediante la evaluación de la complejidad de los componentes del sistema.
Estudios muestran que el mayor esfuerzo de mantenimiento se gasta en un número relativamente pequeño de componentes.
La complejidad depende de:
Las métricas de proceso pueden ser utilizadas para evaluar la mantenibilidad.
Si alguno se incrementa puede indicar que está disminuyendo la mantenibilidad.
Es la reestructuración o la reescritura de parte o todo un sistema heredado sin cambiar su funcionalidad.
Es aplicable cuando los sistemas necesitan un mantenimiento frecuente.
La reingeniería involucra agregar esfuerzo para hacer que sea más fácil mantener el sistema.
EI sistema puede ser reestructurado y redocumentado.
La refactorización es el proceso de hacer mejoras a un programa para reducir la degradación del sistema al realizar cambios.
Se puede pensar en la refactorización como un "mantenimiento preventivo" que reduce los problemas en cambios futuros.
La refactorización trata de modificar un programa para mejorar su estructura, reducir su complejidad o hacerlo más fácil de entender.
Cuando se refactoriza un programa no se deben agregar funcionalidades.
Es inherente a las metodologías ágiles.
La reingeniería toma lugar luego de que el sistema ha sido mantenido por algún tiempo y los costos se incrementan.
Utiliza las herramientas automatizadas para procesar y rediseñar sistemas heredados para crear un nuevo sistema más mantenible.
La refactorización es un proceso continuo de mejora en todo el proceso de desarrollo y en la evolución.
Se tiene la intención de evitar que se incremente la degradación de la estructura y el código para que así no se dificulte el mantenimiento del sistema.
Señales de que el código puede ser mejorado.
¿Qué "bad smell" puede haber en el código?